PokerTracker Corrects Issues with Version 4.11

If you missed it, PokerTracker Version 4.11 was a major breakthrough for users and developers of custom stats, but this software release didn't't occur without a few problems.  PokerTracker representative Steven McLoughlin (pictured) answered a few of our questions about this major release, what the problems were, how they are being resolved, and what was learned from the experience.
 
PokerSoftware:  Tell us a bit about PokerTracker 4.11.
 
Steve McLoughlin:  PokerTracker 4.11 is a major breakthrough for PokerTracker 4.  It defines how PokerTracker can be used by our power users without slowing them down.  PokerTracker 4.11's principal new feature is the inclusion of  database caching for custom stats for the first time; we have been working on this very complicated update for the past half-year.
 
PokerSoftware:  How is a stat normally created in PokerTracker and what is the importance of caching?
 
Steve McLoughlin:  Stats are PokerTracker 4 "objects" that do not exist in the database; instead, stats are also composed of PokerTracker 4 columns.  This allows multiple stats to use the same building blocks, but these blocks aren't necessarily stored in the database.  Each columnn records a specific action or opportunity to take that action.  For example, the stat for VPIP is consists of a column counting the total number times the player voluntarily put money in the pot and another column that is the total number of opportunities there were for that player to put money in the pot.

The stat is calculated by taking the VPIP Action column and then dividing it by the VPIP Opportunity column.  We then multiply this by 100 to display the stat in percentage form. The default columns in PokerTracker 4 can be stored  in a database cache of pre-calculated results, but custom columns could not be cached until PT4.11.

When the data in a column is cached, it means the data in the column is pre-calculated.
After each hand is imported, the cache is then updated with the new recalculated result.  Caching makes the database respond very fast; un-cached columns result in very slow custom stat updates.
 
PokerSoftware:  How does this change with custom stats?
 
Steve McLoughlin:  One of the cool things about PokerTracker 4 is that we have always allowed custom stats.  This means if we don't have a stat that is already predefined in PokerTracker 4, any end user or third-party developer can actually create that stat.  This way you can do your post-game analysis with reports or graphs that contain stats that are the most meaningful to you.

You can also create a custom HUD that incorporates advanced stats that help you visualize what is occurring at the table.  For example, companies like ProPokerHUDs and CoffeeHUD actually create stats that you or I normally wouldn't't consider to be stats.  They use custom stats in new ways to visually describe the same information rather than provide it in numbers.
 
So that was what PokerTracker 4.11 was designed to do.  It was designed to allow our developers and third party users to cache custom stats for the first time, improving PokerTracker 4's performance so it is better than ever before.
 
PokerSoftware:  What were the problems with the PokerTracker 4.11 release?
 
Steve McLoughlin: The first was that a database update was required and not everyone likes to go through a database update since it can take a long period of time, which would interfere with playing online.  If you have a small database, the update won't take much time.  However, if you have a really large database such as a 13 GB database, an update can take up to 24 hours depending on your computer setup.  Simply put, the faster your computer can process data using the postgreSQL database, the faster the update will be.

The speed of your hard drive is probably the most important factor, followed by the processor and your available memory. Unfortunately, there can be many users who skip this stage, which is not advised at all because any time a database update is required, it means the software update won't work properly until a database update is implemented.  For the most part, we were able to work through those users who did not understand that process, but it is always a challenge educating some of our users anytime a database update must occur after a new PT4 release.
 
The other part of the problem is what caught us off-guard.  We were Alpha testing PokerTracker 4.11 for a period of three months and were actually developing this version for over six months, a very long period of time compared to our typical release schedule.
 
During this process, we worked with our volunteer Alpha testers as well as major premium third-party add-on developers such as the guys behind CoffeeHUD and ProPokerHUDs.  Our thought process about bringing in these major third-party add-on developers was that these were people who have created the largest group of commercial third-party custom stats we have seen so far, which should have made it easier to catch bugs.  Between our standard Alpha testers and our third-party developer Alpha testers, we were pretty sure we would cover all the bases.
 
What we didn't expect, however, were some edge case scenarios that would not be easily caught.  For example, we didn't expect to see a scenario where a column contained a formula within a formula that addressed a specific table in the database, so we didn't have the code in place to address some of these edge case scenarios.
 
Another thing that caught us off-guard was that we didn't prepare for what would happen if one custom column name from one custom stat matched another custom column name from another stat from a different third-party developer.  We incorporated duplicate name verification, but we didn't account for differences in the name solely based on capitalization.

So, what would happen is in the past you could create a custom column called "Jaxon_poker" with the "J" capitalized and someone else would create a custom column called "jaxon_Poker" with the "P" capitalized.  That was acceptable until PT4.11.  Now, we are caching columns' postgreSQL automatically converts the column names to all lower case letters.  This was a recipe for disaster; once we figured this out, we were forced to convert all column names internally to address for this potential for conflict caused by capitalization issues.
 
PokerSoftware:  Was there anything else that caught you off-guard?
 
Steve McLoughlin:  There were also some other issues we didn't expect.  There are numerous users using antiquated versions of PostgreSQL.  Unfortunately, some of our code in PT4.11 was not optimized to support these earlier versions, which would halt the database update process.  Even though these earlier versions are not officially supported, we still include support for all updated versions of PostgreSQL 8.3 or 8.4 because those are what many end users have installed.  Until we fixed this problem with 4.11.6, it resulted in some users experiencing failed database updates. 
 
PokerSoftware:  How did PokerTracker react to the problems with the 4.11 release?
 
Steve McLoughlin:  We had a choice.  We could either go through the standard update process that we normally go through, which is code for a brand new release, send it out to Alpha testers, spend a few weeks testing every possible scenario we could think of, finding all the bugs, and then release.  Or, we could work to immediately push out updates that would address individual problems and cross our fingers and hope we get it right with each incremental small update.
 
Since there were so many users adversely affected after we released 4.11, we decided to put out new releases as quickly as possible in order to fix these issues.
 
We immediately released Version 4.11.1, which was only designed to fix a fraction of the problems.  This release allowed us to fix the cache-naming problem with capitalization.  However, when we fixed this, we accidentally created more problems.  It created a scenario where we already had some custom columns were now further conflicting due to nomenclature issues.

In addition, we were not able to fix all the issues that affected all the software's users and that understandably created some anger within the PokerTracker user community.  There were some beliefs that we weren't properly Alpha testing before we put out this release.  While we were testing, however, we were in a huge rush to put out a release that could address individual components we knew we could fix immediately.  Therefore, we were only testing the components that we were fixing rather than the entire release.
 
We then released as an intermediary step Version 4.11.2, which completely fixed the nomenclature problem.  We followed that up with a rush to release Version 4.11.3, which we incorrectly thought would be our final major release to solve these problems.

While coding 4.11.3, we focused on issues related to the cache, which was really the core problem of 4.11.  In the process, we made an error: all of our testing was done by using existing database hands and making sure the database would perform quickly.  Because we were so hyper-focused on releasing this as quickly as possible, we neglected to see how cache updates would occur while importing. 

Unfortunately with our cache fix, which worked correctly, it broke the cache updating process, which is used by the import stage while playing live.  To understand this better, when we import hands, we break them down into their individual components, recording the individual actions and opportunities to take an action, and then update the cache or the pre-calculated result.  With our 4.11.3 fix, we broke the process that was calculating the pre-calculated result during live import, meaning everyone was affected by the 4.11.3 release.  This time, it was not just the users that had custom stats installed.
 
This is a huge embarrassment on our part and we fully acknowledge this error.  Our intentions were good because we were trying to rush out a release to help users who were in need, but in the process we ended up hurting everybody.  For that, we are extremely sorry.  We have learned from this lesson and will make sure going forward that we never put out a rush release in the future without first testing the cache updating process for live imports.
 
PokerSoftware:  So what's next?
 
Steve McLoughlin:  We are happy to say that PokerTracker 4.11.6 was just released, which fixed all of the major issues introduced since 4.11.
 
In the process of putting out these releases, we realized that our traditional Alpha testing process of using private Alpha testers, internal programmers, and our third-party developers to find our bugs was flawed.  The flaw is that this process takes too long and may not catch all of the edge case scenarios.

We decided after the release of 4.11.3 that we would start publicly releasing our Alpha versions.  They will only be released on our forums when we feel the need to have a wider audience and will not support it outside the thread it was released in.  We typically will only announce it where players discuss problems with a certain feature if the Alpha is designed to address that feature.  For example, we only promoted the Alpha versions after 4.11.3 to users that were experiencing cache updating issues in our forums found at PokerTracker.com.
 
This helped us Alpha test Version 4.11.4 very quickly and found that this version was not acceptable once we discovered problems that remained for PostgreSQL 8.3 users.  We then were able to release, within 24 hours, PokerTracker 4.11.5 as an Alpha and gave extra instructions to PostgreSQL 8.3 users who must manually update their cache.  The net result was PokerTracker 4.11.6, the new gold standard for tracking performance.

Visit PokerTracker's website today.

More articles